Data streaming, e.g. unicast or multicast streaming might be performed from any source to a plurality of communication nodes that are interconnected tree-like so that every node is coupled, either via a direct interconnection or via interconnection involving one or a plurality of intermediate nodes, to the source. One problem is to handle faults within the tree; e.g. a link failure or a node failure.
In the following some examples are described about building and rebuilding communications trees:
Protocol Independent Multicast Sparse Mode (PIM-SM) is a well known and commonly applied protocol for building up and maintaining multicast trees in IP networks. This solution uses a single tree for forwarding packets to routers with hosts (destinations in the sequel) wanting to receive the content. PIM-SM is called “protocol independent” because it can use route information that any routing protocol enters into the multicast Routing Information Base.
When a router wants to join or leave a multicast group, it can do it using PIM-SM using simple unicast forwarding. When a node wants to join to a multicast tree using PIM-SM, it sends a JOIN message back towards the source (or towards the rendezvous point for shared tree; in the sequel we will not distinguish between these two anymore) More precisely, the last hop router of the destination may send some JOIN messages to the source (source-based tree) or to the rendezvous point (shared tree). The JOIN packet is routed along a path determined by Multicast RIB (MRIB). The routes in a corresponding table are, in practice, taken directly from the unicast routing table, but they could be different and provided by a separate routing protocol. The MRIB is used to determine the next-hop neighbor to which any PIM Join/Prune message is sent. JOIN is routed and processed hop-by-hop until a node already receiving the traffic is reached. All routers along this path process the JOIN message and install/update multicast routing state (e.g. adding the incoming interface to the outgoing interface list). Data flows along the reverse path of the JOIN messages. (It is to be noted that due to the MRIB being built by unicast routing protocols in practice, PIM JOIN packets are forwarded along the shortest path to the rendezvous point or to the source, which may differ from the shortest downstream path in the case of asymmetric link costs. As a consequence, multicast streams established with PIM potentially use suboptimal paths downstream (e.g. reverse shortest paths). Later, multicast packets will be forwarded along this path. Similarly, a destination wanting to leave the group sends a PRUNE packet up the tree. More detailed information about PIM SM can be drawn e.g. from the IETF document RFC46011.
In Multiprotocol Label switching (MPLS) networks, a multicast distribution tree is built up by means of the Multicast Label Distribution Protocol (MLDP). This might be performed by using a MLDP Label Map message sent from the egress points of the tree towards the root of the tree (the root in the MPLS network). Conceptually, the effect of the MLDP Label Map message is similar to the PIM Join message as discussed above. The MLDP Label Map message also goes upstream and immediately installs the MPLS labels to be used downstream.
PIM-SM depends on unicast routing such that if the routing fails, it must wait for the unicast routing to recover, thus making the convergence relatively slow. Since PIM-SM is commonly for building up paths for real-time traffic (e.g. for IPTV), this slow convergence can be a serious drawback. The same is true for MLDP.
Solutions for fast rerouting exist. E.g. a solution called SmartEdge proposed by Ericsson uses a so-called “dual join” to create a secondary connection for an incoming multicast stream to provide an immediate alternative in a case that the node lose its connection with its primary upstream neighbor. However, dual join cannot guarantee that each of the failures can be handled. Moreover, dual join is a “1+1” protection technique, which means that the alternate traffic is always present, even in a failure free situation, so this solution easily causes significant extra load in the network, especially with respect to high bandwidth traffic, e.g. HD IPTV streams.